Systems and methods for facilitating purchases at a gas station

ABSTRACT

A computing system for remotely activating a transaction device including at least one memory having instructions stored thereon that, when executed by the at least one processor, cause the at least one processor to receive, from a mobile device, a transaction device identifier, receive, from the transaction device, an authorization request associated with a payment account for a transaction at the transaction device, receive location information from the mobile device and location information from the transaction device in response to receiving the authorization request, compare the location information to determine whether the mobile device is in proximity to the transaction device, and upon determining that the mobile device is in proximity to the transaction device, determine an authorization status of the authorization request, and transmit a signal to activate the transaction device to complete the transaction, wherein the signal is transmitted based on the transaction device identifier.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/803,766, filed Feb. 27, 2020, which in turn claims priority to U.S.application Ser. No. 14/855,679, filed Sep. 16, 2015, the entireties ofwhich are incorporated by reference herein for all purposes.

BACKGROUND

Mobile transactions, such as those performed by mobile applications, arebecoming more commonplace. However, these systems typically only allowusers to provide electronic payment information to a merchant, withoutallowing for the selection of goods to be provided from an automatedsystem, such as a fuel pump or vending machine. Additionally, mobiletransactions can be difficult to authenticate as there is no need for aphysical payment media, only a mobile device. Improvements in mobiletransaction security are desired.

SUMMARY

The present disclosure is directed to systems and methods facilitatingpurchases at a gas station or other merchant, as well as providingmobile application payment sharing solutions. Additionally,authentication techniques are provided that may be particularly usefulin verifying a user's identity when conducting mobile transactions.

In one aspect, a method of remotely activating a transaction deviceusing a mobile device is provided. The method may include receiving, ata computing system, a mobile device identifier from a mobile applicationexecuted on a mobile device within a detection range of a transactiondevice. The mobile device identifier may be associated with the mobiledevice. The method may also include receiving a selection of thetransaction device from the mobile application. The selection mayinclude an identifier associated with the transaction device. The methodmay further include receiving from the mobile application a selection ofa transaction amount related to purchase of a product. The method mayinclude communicating an authorization request for a payment accountassociated with the mobile device to an issuer of the payment account.The authorization request may be for a transaction of at least thetransaction amount. The method may also include receiving anauthorization approval for the transaction from the issuer and sending asignal to activate the transaction device to dispense the product. Thesignal may be transmitted based on the identifier associated with thetransaction device. The method may further include deactivating thetransaction device upon dispensing the transaction amount and providinga receipt of the transaction to the mobile device.

In another aspect, a method of remotely activating a transaction deviceusing a mobile application executed on a mobile device is provided. Themethod may include determining that the mobile device is within adetection range of a transaction device and providing a mobile deviceidentifier associated with the mobile device to a computing device. Themethod may also include providing a selection of the transaction deviceto the computing device. The selection may include an identifierassociated with the transaction device. The method may further includereceiving, on a user interface of the mobile application, a selection ofa transaction amount related to a purchase of a product. The method mayinclude providing an authorization request for the transaction amount tothe computing device such that upon authorization of the transactionamount the transaction device is activatable by the computing device todispense the product. The method may also include receiving a receipt ofthe purchase upon the product being dispensed.

In another aspect, a method of enrolling a mobile device for use inmobile transactions is provided. The method may include receiving, at acomputing device, an input from a point of sale device of a merchant.The input may include a payment information associated with a paymentmedia and originating from an interaction of the payment media with apayment reader of the point of sale device during a purchasetransaction. The method may also include storing the payment informationand receiving a mobile device identifier from the point of sale device.The method may further include sending a communication to a mobiledevice associated with the mobile device identifier. The communicationmay provide access to a download for a mobile application associatedwith the merchant. The method may include associating the mobile deviceidentifier with the payment information and receiving authenticationcredentials from the mobile application being executed on the mobiledevice. The authentication credentials may include a user identifier andpassword. The method may further include creating a user accountassociated with the mobile device identifier, the payment information,and the authentication credentials.

In another aspect, a method of setting up shared payment account forconducting mobile transactions is provided. The method may includereceiving payment information from a first mobile application executedon a first mobile device. The payment information may be associated witha payment account of a verified user. The method may also includereceiving, from the first mobile application, a selection of a seconduser to be added as an authorized user of the payment account. Thesecond user may have a user identifier. The method may further includeproviding a notification to the second user that the second user hasbeen added by the verified user as an authorized user of the paymentaccount. The notification may be directed to the second user using theuser identifier. The method may include receiving a confirmation messagefrom a second mobile application executed on a second mobile device ofthe second user. The confirmation message may include authenticationinformation associated with the second user. The method may also includeadding the second user as an authorized user of the payment account.

In another aspect, a method for requesting funds from another user isprovided. The method may include receiving a request for a payment froma first mobile application executed by a first mobile device. Therequest may include a transaction amount and a user identifierassociated with a second user account and a second mobile device. Themethod may also include receiving a user authentication from the firstmobile application to verify an identity of a user of the first mobiledevice. The method may also include communicating a message to thesecond mobile device using the user identifier. The message may includea request to provide funds for the transaction amount. The method mayfurther include receiving an acceptance of the request to provide fundsfrom a second mobile application being executed by the second mobiledevice. The method may include authorizing a payment account associatedwith the second user account for the payment such that the first mobiledevice may complete a related payment transaction in real-time. Themethod may further include providing a receipt of the paymenttransaction to the second mobile device.

In another aspect, a method of conducting mobile transactions using amobile application is provided. The method may include receiving anodometer reading of a vehicle and interfacing with a telematicsinterface of the vehicle. The method may also include receiving atelematics input from the telematics interface. The telematics input mayinclude a status of one or more systems of the vehicle. The method mayfurther include setting one or more service notifications based on theodometer reading and the telematics input and presenting at least one ofthe one or more service notifications on a display of a mobile deviceexecuting the mobile application. The method may include receiving arequest to schedule a service appointment related to the at least one ofthe one or more service notifications and receiving a schedule ofavailable service times from a service provider. The method may alsoinclude providing a scheduling user interface that may include theschedule of available service times on the display of the mobile device.The method may further include receiving a selection of the serviceappointment comprising at least one of the available service times andcommunicating the selection to the service provider.

In another aspect, a method of fraud prevention and authentication isprovided. The method may include receiving a request for a transactionand performing two or more authentication measures. The method mayfurther include determining a result for each of the two or moreauthentication measures and computing a weighted score based on theresults of the two or more authentication measures. The method mayfurther include determining whether to authenticate the transactionbased at least in part on the weighted score.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of variousembodiments may be realized by reference to the following figures. Inthe appended figures, similar components or features may have the samereference label. Further, various components of the same type may bedistinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

FIG. 1 is a system diagram showing a system for conducting mobiletransactions according to embodiments.

FIG. 2 is a system diagram showing an example mobile application blockdiagram for conducting mobile transactions according to embodiments.

FIG. 3 is a system diagram showing a system for enrolling a mobiledevice in a mobile transaction system according to embodiments.

FIG. 4 is a flowchart of a process for enrolling a mobile device in amobile transaction system according to embodiments.

FIG. 5 is a system diagram showing a system for remotely activating atransaction device according to embodiments.

FIG. 6 is a flowchart of a process for remotely activating a transactiondevice according to embodiments.

FIG. 7 shows a user interface of a mobile application for remotelyactivating a transaction device according to embodiments.

FIG. 8 is a flowchart of a process for remotely activating a transactiondevice using a mobile device according to embodiments.

FIG. 9 is a flowchart of a process for setting up a shared paymentaccording to embodiments.

FIG. 10 is a flowchart of a process for requesting funds for atransaction from another user according to embodiments.

FIG. 11 is a system diagram showing a system for scheduling vehicleservice using a mobile application according to embodiments.

FIG. 12 is a flowchart of a process for scheduling vehicle service usinga mobile application according to embodiments.

FIG. 13 is a flowchart of a process for fraud prevention andauthentication according to embodiments.

FIG. 14 is a block diagram of an example computing system according toembodiments.

DETAILED DESCRIPTION

The present disclosure is directed to systems and methods facilitatingpurchases at a gas station or other merchant, as well as providingmobile application payment sharing solutions. Certain exampleembodiments of the disclosure will now be described more fullyhereinafter with accompanying drawings and corresponding description inFIGS. 1-13.

This disclosure may, however, be embodied in many different forms andshould not be construed as limited to the embodiments set forth herein.

An example architecture or environment for a system 100 accordingvarious example embodiments of the disclosure is shown in and describedwith respect to FIG. 1. A mobile commerce application program or module,such as 102, can be stored in memory 104 at a server device 106. Incertain embodiments, a mobile commerce application program or module,such as 108, can be stored in memory 110 at a merchant system computer112 or associated merchant device 114. In certain embodiments, a mobilecommerce application program or module, such as 116(1), can be stored inmemory 118(1) at a mobile device 120(1) associated with a consumer122(1) or user. In any instance, one or more mobile commerce applicationprograms or modules operating on respective computers, servers and/ormobile devices can implement some or all of the functionality describedherein.

System 100 may include or otherwise support one or more merchant systemcomputers 112 and/or associated merchant devices 114, one or moreconsumer or mobile devices 120(1)-120(N), one or more server transactionprocessing systems 106, and one or more issuer or financial institutionsystems 124. A wide variety of different types of consumer or mobiledevices 120(1)-120(N) may be provided or otherwise supported, such asconsumer computers and/or mobile communication devices. As desired, thesystem 100 may provide or otherwise support a wide variety of otherentities associated with payment transactions, such as one or moreserver transaction processing systems 106. Any number of suitablenetworks and/or communication channels, such as the illustrated networks126, may facilitate communication between various components of thesystem 100.

Any number of merchant system computers 112 and/or associated merchantdevices 114 may be provided or otherwise supported. In certain exampleembodiments, these merchant system computers 112 and/or associatedmerchant devices 114 may include one or more point-of-sale (POS)devices, transaction devices, and/or terminals. As desired, eachmerchant system computer 112 and/or associated merchant device 114 mayinclude any number of processor-driven devices, including but notlimited to, a server computer, a mainframe computer, one or morenetworked computers, a desktop computer, a personal computer, a laptopcomputer, a mobile computer, a smartphone, a tablet computer, a wearablecomputer device, an application specific circuit, and/or any otherprocessor-based device.

A merchant system computer 112 and/or associated merchant device 114 maybe any suitable device that facilitates purchase transactions, such asthose in retail establishments, e-commerce and/or mobile transactions.In operation, the merchant system computer 112 and/or associatedmerchant device 114 may utilize one or more processors 128 to executecomputer readable instructions that facilitate the hosting of one ormore mobile commerce application program services, the receipt ofpurchase transaction requests, and/or the processing of paymenttransactions. As a result of executing these computer-readableinstructions, a special purpose computer or particular machine may beformed that facilitates the purchase transactions.

In addition to having one or more processors 128, the merchant systemcomputer 112 and/or associated merchant device 114 may further includeand/or be associated with one or more memory devices 110, input/output(“I/O”) interface(s) 130, network interface(s), and/or location services132. The memory 110 may be any computer-readable medium, coupled to theprocessor(s) 128, such as random access memory (“RAM”), read-only memory(“ROM”), and/or removable storage devices. The memory 110 may store awide variety of data files 164 and/or various program modules, such asan operating system (“OS”) 165, one or more host modules, and/or one ormore transaction modules or transaction applications, such as mobilecommerce application program 108. The data files 164 may include anysuitable data that facilitates the operation of the merchant systemcomputer 112 and/or associated merchant device 114, and/or interactionof the merchant system computer 112 and/or associated merchant device114 with one or more other components (e.g., one or more one or moreconsumer or mobile devices 120(1)-120(N), one or more server transactionprocessing systems 106, one or more merchant acquiring platforms, one ormore issuer systems, one or more financial institution systems 124,etc.) of the system 100. For example, the data files 164 may includeinformation associated with one or more websites 134 (hosted by either athird-party and/or merchant), webpages, inventory information associatedwith available products and/or services, acquiring platform information,service provider information, merchant-specific information (such as thenumber of fuel dispensing pumps and the products and services offered bythe merchant), information associated with the generation of paymenttransactions, customer information, demographic data, and/or routinginformation for payment transactions.

The OS 165 may be any suitable module that facilitates the generaloperation of the merchant system computer 112, as well as the executionof other program modules. For example, the OS 165 may be any currentlyknown or future developed operating system including, but not limitedto, Microsoft Windows®, Apple OSX™, Unix, a mainframe computer operatingsystem (e.g., IBM z/OS, MVS, OS/390, etc.), or a specially designedoperating system. The host modules may include any number of suitablehost modules that manage interactions and communications between themerchant system computer 112 and/or associated merchant device 114, andone or more external devices, such as the consumer or mobile devices120(1)-120(N). For example, the host modules may include one or more Webserver modules that facilitate the hosting of merchant websites and/orthird-party websites, such as website(s) 134, webpages, and/ortransaction processing webpages. As another example, the host modulesmay include one or more cellular modules and/or systems that facilitatecellular communication with one or more mobile devices 120(1)-120(N).

The transaction modules or applications, such as the mobile commerceapplication program 108, may include any number of suitable softwaremodules and/or applications that facilitate the collection and/orprocessing of information association with a purchase transaction, suchas one or more identifiers of desired products (e.g., UPC identifiers)and/or services, a desired payment account, a desired type oftransaction (e.g., a card present transaction, a card not presenttransaction, etc.), consumer identification information, and/or anidentifier of a consumer or mobile device 120(1)-120(N) (e.g., a mobiledevice identifier, etc.). Based at least in part upon the collectedinformation, the transaction modules or applications may generate and/orcommunicate a wide variety of transaction-related requests, such aspayment processing and/or authorization requests and/or advertisingrequests. One example of the operations that may be performed by atransaction module or mobile commerce application program 108 and/or themerchant system computer 112 and/or associated merchant device 114 isdescribed in greater detail below with reference to FIG. 2.

With continued reference to the merchant system computer 112 and/orassociated merchant device 114, the one or more I/O interfaces 130 mayfacilitate communication between the merchant system computer 112 and/orassociated merchant device 114 and one or more input/output devices; forexample, one or more user interface devices, such as a display, akeypad, a mouse, a pointing device, a gesture detection device, an eyemovement detection device, a control panel, a touch screen display, aremote control, a microphone, a speaker, a consumer device reader, etc.,that facilitate user interaction with the merchant system computer 112and/or associated merchant device 114. The one or more networkinterfaces may facilitate connection of the merchant system computer 112and/or associated merchant device 114 to one or more suitable networks,such as 126, and/or communication links. In this regard, the merchantsystem computer 112 and/or associated merchant device 114 may receiveand/or communicate information to other components of the system 100,such as the consumer or mobile devices, for example 120(1)-120(N), theserver transaction processing systems 106, and/or the issuer orfinancial institution systems 124.

In certain example embodiments, a merchant system computer 112 and/orassociated merchant device 114 can be associated with a merchantlocation 136, such as a retail store (e.g., gas station) or “bricks andmortar”-type establishment. The merchant location 136 and/or merchantdevice 114 may include a code 138, such as a QR code, bar code, radiofrequency identifier (RFID) tag, and/or other machine readable code,wherein consumers can utilize a respective consumer or mobile device120(1)-120(N) to scan or read the code to check-in to a merchant or toobtain information associated with a merchant, such as product pricinginformation. Alternatively, the merchant system computer 112 and/or theassociated merchant device may include or be communicably coupled togeolocation devices that are operatively coupled to one or more locationservices 132 for sensing and identifying customer mobile devices thatare within a predetermined distance of the merchant location.

Additionally, any number of consumer or mobile devices 120(1)-120(N) maybe provided or otherwise supported. Examples of suitable consumer ormobile devices can include, but are not limited to, personal computersand/or mobile communication devices (e.g., mobile phones, smart phones,etc.), etc. According to an example aspect of the disclosure, a consumeror mobile device, such as 120(1) may be a suitable device that iscapable of interaction with other components of the system 100 duringthe request and/or completion of an e-commerce transaction. For example,a personal computer or mobile device may be utilized to access one ormore e-commerce websites, such as website(s) 134, including those hostedby the merchant system computer 112 and identify products and/orservices to be purchased, request a purchase and/or interact with themerchant system computer 112, merchant system device 114, and/or othercomponents of the system 100 (e.g., the server transaction processingsystem 106, etc.) during the completion of a payment transaction. In oneexample embodiment, a mobile device, such as 120(1), may be utilized torequest one or more products and/or services in a payment transaction,provide consumer identification information, and/or to providevalidation information during the processing of the payment transaction.

As desired, a consumer or mobile device, such as 120(1), may be anynumber of processor-driven devices, including but not limited to, apersonal computer, a mobile computer, an application-specific circuit, aminicomputer, a microcontroller, and/or any other processor-baseddevice. The components of an example mobile device, such as 120(1), willnow be described in greater detail, and it will be appreciated that apersonal computer may include similar components. With reference to themobile device 120(1), the mobile device 120(1) may utilize one or moreprocessors 140(1) to execute computer-readable instructions thatfacilitate the general operation of the mobile device 120(1) (e.g., callfunctionality, etc.) and/or communication with a merchant systemcomputer 112, merchant system device 114, and/or other components of thesystem 100 (e.g., the server transaction processing system 106) forproduct selection and payment transaction purposes, for providing accessto purchased products, as well as for the receipt of merchant selectedadvertising, loyalty awards, coupons and promotional information. As aresult of executing these computer-readable instructions, a specialpurpose computer or particular machine may be formed that facilitatesthe completion of payment transactions, provides access to purchasedproducts, and/or provides for the receipt of loyalty awards, couponsand/or promotional information.

In addition to having one or more processors, the mobile device, such as120(1)-120(N), may further include and/or be associated with one or morememory devices 118(1)-118(N), input/output (“I/O”) interfaces142(1)-142(N), network interfaces, and/or location services144(1)-144(N). The memory 118(1)-118(N) may be any computer-readablemedium, coupled to the one or more processors 140(1)-140(N), such asrandom access memory (“RAM”), read-only memory (“ROM”), and/or removablestorage devices. The memory 118(1)-118(N) may store a wide variety ofdata files and/or various program modules, such as an operating system(“OS”) 156(1)-156(N) and/or one or more transaction modules orapplications, such as a mobile commerce application program116(1)-116(N). In certain example embodiments, a mobile device, such as120(1), may include one or more secure elements 155(1)-155(N) configuredto securely store and/or access information, such as paymentapplications, payment account information, validation information (e.g.,a stored mPIN, etc.), encryption information, and/or othertransaction-related information. The secure elements 155(1) may bestored in the memory 118(1) and/or included as a separate component ofthe mobile device 120(1). For example, a secure element 155(1)-155(N)may be a separate chip that is configured to communicate with primarycomputing functionality for the mobile device. As desired, one or moreof the transaction modules, such as the mobile commerce applicationprogram 116(1), may be stored on a secure element. The transactionmodules may be invoked by other components of the mobile device 120(1)and/or by one or more other components of the system 100, such as themerchant system computer 112, merchant system device 114, and/or theserver transaction processing system 106.

The data files may include any suitable data that facilitates theoperation of the mobile device, such as 120(1), and/or interaction ofthe mobile device 120(1) with one or more other components (e.g., amerchant system computer 112, merchant system device 114, a servertransaction processing system 106, etc.) of the system 100. For example,the data files may include information associated with accessing thesecure elements 155(1)-155(N), information associated with invokingtransaction modules, and/or information associated with accessing and/orprocessing validation data (e.g., an mPIN, etc.). The OS 162(1)-162(N)may be a suitable module that facilitates the general operation of themobile device, such as 120(1), as well as the execution of other programmodules. For example, the OS 162(1)-162 (N) may be any currently knownor future developed operating system including, but not limited to, asuitable mobile OS or a specially designed operating system. As desired,the mobile device 120(1) may also include one or more suitable browserapplications that facilitate the access of one or more webpages hostedby the merchant system computer 112, and/or third-party or merchantwebsites, such as 134.

The transaction modules may include one or more suitable softwaremodules and/or applications configured to facilitate purchasetransactions, such as payment transactions, facilitate the receipt anddisplay of loyalty awards, coupons and/or promotional information,and/or provides access to purchased products on behalf of the mobiledevice, such as 120(1). In certain embodiments, a transaction module ormobile commerce application program, such as 116(1), may also facilitatecommunication with a server transaction processing system, such as 106,or a trusted service manager. A wide variety of suitable techniques maybe utilized to install a transaction module on the mobile device, suchas 120(1). For example, a transaction module may be provisioned to themobile device 120(1) by a server transaction processing system 106and/or by an issuer or financial institution system 124. Additionally,during the installation and/or registration of the transaction module, awide variety of validation information may be generated and/oridentified. For example, a consumer, such as 122(1) may be prompted toenter an mPIN, such as a multi-character and/or multi-numeral code, toan associated mobile device, such as 120(1). As desired, the mPIN may bestored on a secure element 155(1)-155(N). Additionally, the PIN and/or awide variety of information derived from the mPIN (e.g., an encryptedmPIN, etc.) may be provided to one or more issuer or financialinstitution systems, such as 124, or an issuer system associated with anissuer of a payment account (e.g., a credit account, a debit account, apre-paid card account, a gift card account, a stored value account,etc.) that is associated with the transaction module.

According to an aspect of the disclosure, following registration and/oractivation of the transaction module, the transaction module may beinvoked during a payment transaction. For example, the transactionmodule may be invoked by a merchant system computer 112, merchant systemdevice 114, or by a server transaction processing system 106 at therequest of the merchant system computer 112 and/or merchant systemdevice 114. In certain example embodiments, the transaction module maybe invoked following a consumer request to conduct a payment transactionand the identification of the mobile device, such as 120(1), by themerchant system computer 112, merchant system device 114, or servertransaction processing system 106. Following the invocation of thetransaction module, a request for validation data and/or payment accountdata may be received. As desired, the transaction module may prompt theconsumer for entry of an mPIN, and an mPIN value entered by theconsumer, such as 122(1), (e.g., by a keypad, touchscreen, etc.) may beidentified. A stored mPIN value may then be accessed from the secureelement 155(1)-155(N) and compared to the entered mPIN value. In thisregard, the entered mPIN value may be authenticated. If the entered mPINvalue is not authenticated, then the transaction module may reject aproposed transaction and direct the output of a suitable error message.

If, however, the entered mPIN value is authenticated, then thetransaction module may provide payment account data and associatedvalidation data to the merchant system computer 112, merchant systemdevice 114, or server transaction processing system 106. A wide varietyof different types of validation data may be provided as desired invarious embodiments, including but not limited to, an mPIN entered bythe consumer 122(1), an indication that the entered mPIN wasauthenticated by the mobile device 120(1) and/or the secure element155(1), an encrypted version of the entered mPIN, and/or an encryptedversion of the stored mPIN. In one example embodiment, an entered mPINmay be authenticated, encrypted, and provided to the merchant systemcomputer (or a server transaction processing system). In this regard,the encrypted mPIN may be provided to the issuer or financialinstitution system, such as 124, for authentication and/or risk analysispurposes.

The one or more I/O interfaces, such as 142(1)-142(N), may facilitatecommunication between the mobile device, such as 120(1) and one or moreinput/output devices; for example, one or more user interface devices,such as a display, a keypad, a touch screen display, a microphone, aspeaker, etc., that facilitate user interaction with the mobile device120(1). Further, the one or more network interfaces may facilitateconnection of the mobile device, such as 120(1), to one or more suitablenetworks, for example, the network(s) 126 illustrated in FIG. 1. In thisregard, the mobile device, such as 120(1), may receive and/orcommunicate information to other components of the system 100.

In some embodiments, any number of server transaction processingsystems, such as server transaction processing system 106, may beprovided or otherwise supported. A server transaction processing system106 may facilitate the backend processing of a purchase transaction,such as a payment transaction, the identification of a consumer's mobiledevice 120(1) based on consumer identification information, demographicand/or purchase history information for the consumer associated with theconsumer mobile device 120(1). In certain example embodiments, an issuersystem may include similar components as those discussed above for themerchant system computer 112 and/or merchant system device 114. Forexample, server transaction processing system 106 may include any numberof processors 146, memories, I/O interfaces 148, and/or networkinterfaces. In certain example embodiments, a server transactionprocessing system 106 can include one or more transaction modules, suchas a mobile commerce application program 102 and/or a social networkintegration program application 150. In any instance, the transactionmodules can facilitate communications and/or interactions with anynumber of consumer or mobile devices such as mobile devices120(1)-120(N), merchant computer systems such as 112, merchant computerdevices 114, data stores 151, third-party websites such as 134, andfinancial institution systems such as 124. In certain embodiments, aservice transaction processing system, such as 106, can host a socialnetwork integration program application, such as 150, configured tocommunicate via any number of social network services and/or websites toobtain information from the services and/or websites, for example,product and/or service data 152 on a third party or merchant website,such as 134.

Furthermore, as desired, a server transaction processing system, such as106, may provide a wide variety of transaction module provisioningservices. Additionally, a server transaction processing system, such as106, may provide a wide variety of transaction-related and/or valueadded services (“VAS”) in association with transactions, such astargeted advertising services, coupon redemption services,loyalty/reward services, location-based services, electronic receiptservices, product registration services, warranty services, couponissuance services, and/or the routing of a proposed transaction to anissuer for approval and/or settlement purposes. In certain exampleembodiments, a server transaction processing system, such as servertransaction processing system 106, may include similar components asthose discussed above for the merchant system computer, such as 112,and/or merchant system device, such as 114. For example, a servertransaction processing system, such as 106, may include any number ofprocessors, memories, I/O interfaces, and/or network interfaces.

In some embodiments, any number of issuer or financial institutionsystems, such as 124, may be provided or otherwise supported. An issueror financial institution system, such as financial institution system124, may facilitate the backend processing of a payment transaction,such as a payment for one or more products and/or services selected byan consumer at a merchant location. For example, an issuer or financialinstitution system, such as financial institution system 124, may host apayment processing application program, such as payment processingapplication program 154, or module to facilitate the approval,authentication, and/or settlement of a payment transaction. In certainexample embodiments, a payment transaction may be routed to an issuer orfinancial institution system, such as financial institution system 124,via a suitable transaction network (e.g., a debit network, a creditnetwork, etc.), and the issuer or financial institution system, such asfinancial institution system 124, may evaluate the payment transactionvia the payment processing application program, such as paymentprocessing application program 154, or module. An approval or rejectionof the payment transaction may then be output for communication to amerchant system computer, such as merchant system computer 112, and/ormerchant system device 114. The issuer or financial institution system,such as financial institution system 124, may then facilitate thesettlement of the payment transaction. In certain embodiments, an issueror financial institution system, such as financial institution system124, may include similar components as those discussed above for themerchant system computer 112 and/or merchant system device 114. Forexample, an issuer or financial institution system, such as financialinstitution system 124, may include any number of processors 156,memories 158, I/O interfaces 160, and/or network interfaces. In certainexample embodiments of the disclosure, an issuer or financialinstitution system, such as financial institution system 124, mayreceive validation information in association with a purchase atransaction.

A wide variety of suitable networks, individually and/or collectivelyshown as network(s) 126, may be utilized in association with embodimentsof the disclosure. Certain networks may facilitate use of a wide varietyof e-commerce-related communication. For example, one or moretelecommunication networks, cellular networks, wide area networks (e.g.,the Internet), and/or other networks may be provided or otherwisesupported. Other networks may facilitate communication oftransaction-related communications. For example, one or more transactionnetworks, such as branded networks (e.g., a VISA network, etc.), debitand/or PIN networks, and/or a wide variety of other suitable transactionnetworks may facilitate communication of transaction-relatedcommunications, such as e-commerce transactions. Due to networkconnectivity, various methodologies as described herein may be practicedin the context of distributed computing environments. It will also beappreciated that the various networks may include a plurality ofnetworks, each with devices such as gateways and routers for providingconnectivity between or among networks. Additionally, instead of, or inaddition to, a network, dedicated communication links may be used toconnect various devices in accordance with an example embodiment.

The system 100 shown in and described with respect to FIG. 1 is providedby way of example only. Numerous other operating environments, systemarchitectures, and device configurations are possible. Other systemembodiments can include fewer or greater numbers of components and mayincorporate some or all of the functionality described with respect tothe system components shown in FIG. 1. Accordingly, embodiments of thedisclosure should not be construed as being limited to any particularoperating environment, system architecture, or device configuration.Other known mobile transaction systems are described in U.S. PatentPublication Number 2013/0097031, entitled “Systems and methods forFacilitating Point of Sale Transactions,” which was filed on Oct. 12,2012 and in U.S. Patent Publication Number 2014/0074605, entitled“Systems and methods for Facilitating Purchases at a Gas Station viaMobile Commerce,” which was filed on Sep. 11, 2013, the entire contentsof which are hereby incorporated by reference for all purposes.

FIG. 2 shows an example mobile commerce application program 200, similarto the mobile commerce application programs 102, 108, and 116(1)-116(N)in FIG. 1, that can operate with respect to the system 100 shown inFIG. 1. The mobile commerce application program 200 shown in FIG. 2 caninclude, for example, a loyalty/rewards module 202 that may track auser's purchases and provide coupons, discounts, and/or other rewardsbased on a user's transaction history. Mobile commerce applicationprogram 200 may also include a check-in-to-pay module 204 that checks auser into the application upon detecting the mobile device is inproximity to a transaction device, a notification or messaging module206, a shared payment module 208, a request funds module 210, a mobiledevice login module 212, a bill payment module 214, an service schedulermodule 216, a check-in to pump gas module 218, a buy car wash module220, a tokenization module 222 that may tokenize payment information andother sensitive data, a product/service menu module 224, and/or a codescanning module 226. Some or all of the modules 202-226 are describedherein with respect to certain mobile commerce functionality, associatedprocesses, and features. FIGS. 3-12 illustrate certain processesassociated with some or all of the modules including the example mobilecommerce application program 200 in FIG. 2. While the various modules202-226 are shown by way of example, fewer or greater numbers of modulescan be present in various embodiments of a mobile commerce applicationprogram. Furthermore, various functionality described with respect toone module may be performed by multiple modules in other embodiments ofthe disclosure.

Mobile Application Enrollment

In some embodiments, systems and methods are provided for enrollingcustomers in mobile transaction services. The user's payment media maybe linked to a mobile or web-based application. In one exampleimplementation, a merchant, such as a gas station merchant, can create amobile commerce application program, also known as a mobile app, mobilewallet, or wallet app. A consumer can download the mobile commerceapplication program onto the consumer's mobile device and store certainpersonal and/or payment method information in association with themobile commerce application program. Such enrollment may be particularlysecure, as by enrolling the mobile device and/or application while averified transaction with the payment media is conducted ensures thatboth the mobile device and the payment media must be present. Thisreduces the likelihood of fraud as a user needs to have both items intheir possession.

For example, a user may arrive at a merchant and use a payment card toconduct a transaction at a point of sale device of the merchant. Theuser may be prompted to enter a phone number or other identifierassociated with the user's mobile device and/or an account of the user.An SMS message and/or other communication may be sent to the userincluding a link to a download for a mobile application. The user'spayment information may be associated with the downloaded application.Within the mobile application, the user may select a user ID andpassword or other identity credential, and may then use the mobileapplication to access the payment account for purchases using the mobiledevice.

In the above implementations and other embodiments described herein, amobile commerce application program, sometimes referred to as a mobileapp or wallet app, can be hosted or otherwise stored on a mobile device,client device, server device, or any other processor-based device.Multiple instances of mobile commerce application programs can operatewithin a network environment, such as described in FIG. 1, and each mayhave similar or different functionality, such as described in FIG. 2,according to various example embodiments and implementations asdescribed herein.

FIG. 3 depicts a system 300 for enrolling a user in a mobile transactionsystem. System 300 may include a merchant POS device 302 configured toreceive data, such as payment data, from one or more types of paymentmedia 304. The POS device 302 may be any device capable of conducting apurchase transaction and may include a display, one or more paymentreaders, and/or one or more input devices, such as a touchscreen orkeypad whereby a user may provide additional input. The payment media304 may include credit cards, debit cards, contactless cards, and/orother payment media associated with a payment account. The payment media304 may be able to communicate payment data, such as an identifier ofthe payment account, to facilitate the completion of transactions. Forexample, payment media 304 may communicate the payment data to the POSdevice 302. The payment data may be stored on POS device, a computingdevice in communication with the POS device, and/or on a cloud or remoteserver. The communication of payment data, as well as the communicationof other data, may be used to enroll the user in the mobile paymentsystem. For example, upon receiving the payment information, the POSdevice 302 may receive a determination that the payment account is notlinked to a user account of a mobile transaction system. The POS device302 may query the user as to whether the user would like to enroll, andupon confirmation, may provide a prompt requesting the user's mobilephone number. The payment data and/or phone number may be stored in amerchant system. For example, the POS device 302 may store theinformation locally and/or the POS device 302 may communicate theinformation to a remote and/or central server 308. POS device 302 may bein communication with one or more other components of system 300, suchas central server 308, using a network 306.

Network 306 may be a local area network (LAN) and/or other private orpublic wired and/or wireless networks. Network 306 may utilize one ormore of Wi-Fi, ZigBee, Bluetooth™, Bluetooth™ Low Energy, a cellularcommunications protocol such as 3G, 4G, or LTE, and/or any otherwireless communications protocol. Network 306 may be communicativelycoupled with one or more of the components of the system to facilitatecommunication between the various components. It will be appreciatedthat one or more different network connections may be used in accordancewith the invention, and that the use of a single network 306 to enablecommunications is merely one example of such configurations. Forexample, each component may be communicatively coupled with othercomponents using a separate network for one or more of the connections.

The server 308 may be coupled with a network attached storage (NAS) 310,which can include the one or more databases. NAS 310 stores data for thesystem that is used for facilitating mobile transactions and performingother functions and features described herein. NAS 310 can be any typeof storage device that is accessible over a network, including a storagearea network (SAN). In other embodiments, the databases can be stored inserver 308 rather than on a separate physical machine dedicated to datastorage.

In this embodiment, NAS 310 stores an account database 312 and an mobiledevice database 314. Account database 312 can be used to store useraccounts that are used for payment and conducting other transactions.For example, user identify information, purchase history, discounts,payment account information, and other information associated withaccounts can be stored in account database 312. Mobile device database314 may include identifiers associated with each registered mobiledevice within the system. Databases 312 and 314 may be linked orotherwise associated with one another such that data may becross-referenced between the two. It should be understood that accountdatabase 312 and identifier database 314 are only example databases thatcan be stored in NAS 310. In other embodiments, different or additionaldatabases can also be stored. Additionally, it will be appreciated thatmultiple databases may be merged into a single database.

Upon receipt of the user's phone number, the merchant system (the POSdevice 302, the central server 308, and/or other component of themerchant system) may send a notification to the user's mobile device 316using the phone number. The notification may be in the form of an SMSmessage, push notification, email message, and/or other message thatprovides access to a download of a mobile application usable to conductmobile transactions with the merchant. For example, the notification mayinclude a link to a download source of the mobile application, such as adownload hosted by a merchant website and/or central server 308. Inother embodiments, the notification may direct a user of the mobiledevice 316 to a download location for the mobile application on a mobileapplication database operated by a third party. For example, thedownload location may be an “app store” or other database of mobileapplications. Directing the user to the database may include sending acommand to the user's mobile device 316 to open an application databaseto a specific location or address. In other embodiments, thenotification may include instructions directing the user to navigate tothe download location using a browser of the mobile device 316 and/orusing an application database.

Upon downloading the mobile application, the user may enter into aninterface of the mobile application identity credentials, such as a username, password, biometric input, and/or other identifying information.The identity credentials may be used to access a user account that iscreated and associated with the payment data, mobile application, and/ormobile device 316.

FIG. 4 depicts a flowchart of another embodiment of a process 400 forenrolling a mobile device for use in mobile transactions. Process 400may be performed by one or more components of a system such as system300 described above with regard to FIG. 3. For example, process 400 maybe performed by a merchant POS device, central server, and/or othercomputing device. Process 400 may begin with receiving an input from apoint of sale device of a merchant at block 402. The input may includepayment information associated with a payment media, where the paymentinformation originates from an interaction of the payment media with apayment reader of the point of sale device during a purchasetransaction. For example, a user completing a purchase transaction at amerchant POS device may present a payment media, such as a credit/debitcard, contactless payment card, and/or other payment media associatedwith a payment account, to the POS device. The payment information maybe received from a magnetic strip, microchip, and/or other data storageof the payment media. The payment information may be checked against adatabase of existing mobile transaction accounts to determine whether amobile transaction account exists that is associated with the paymentmedia and/or payment account. For example, a POS device may look up,locally and/or at a central server, whether the payment information isassociated with an existing mobile transaction account. Upon determiningthat the payment information is not associated with an existing account,the user may be queried as to whether he would like to enroll in amobile transaction system at block 404. For example, a message bedisplayed on the POS device prompting the user to select whether or nothe would like to enroll. In embodiments where a central server isperforming process 400, the central server may send a command to the POSdevice to display the prompt. Upon receiving a selection of aconfirmation of a desire to enroll in the mobile transaction system,such as by a user interacting with a button and/or portion of a touchdisplay of a POS device, the payment information received from thepayment media may be stored at block 406. For example, the paymentinformation may be stored in a database of payment accounts in a centralserver or NAS storage, such as described in FIG. 3. At block 408, Amobile device identifier may be received at the point of sale device,which may then be communicated to a central server or other computingdevice.

A notification or other communication may be sent to a mobile deviceassociated with the mobile device identifier at block 410. Thecommunication may provide the user and/or mobile device with access to adownload for a mobile application associated with the merchant. In someembodiments, the communication may include a link to a download sourceof the mobile application. In other embodiments, the notification maydirect a user of the mobile device to a download location for the mobileapplication on a mobile application database. The user may download,install, and execute the mobile application on the mobile device. Themobile device identifier and payment information may be associated withone another at block 412. At block 414, authentication credentials maybe received from the mobile application being executed on the mobiledevice. The authentication credentials may include a username, apassword, a biometric input, other identification information, orcombinations thereof. A mobile transaction account or user account maybe created that is associated with the mobile device identifier, thepayment information, and the authentication credentials at block 416.The account may be set up while the user is completing the transaction.At block 418, a receipt of the transaction may then be sent to themobile application, such as using a push notification, SMS, and/oremail. The user may then utilize the mobile application to completefuture transactions with the merchant.

In some embodiments, either prior to, or upon, the creation of the useraccount additional authentication measure may be taken, such as thosedescribed elsewhere herein. For example, at block 420, locationinformation may be received from the mobile device and the point of saledevice. This may be done using networks such as network 306 describedabove. For example, the mobile application executed on the mobile devicemay retrieve location information, such as GPS data and/or otherlocation data from the mobile device and provide this locationinformation to the central server over a cellular data network, a Wi-Finetwork, and/or other wireless network. In some embodiments, a shortrange network, such as NFC, Bluetooth™, or other short range wirelessnetwork may be used to provide the mobile device's location to the POSdevice, which may relay the location information to the central server.The POS device may communicate its own location to the central server.For example, the POS device may retrieve its own GPS data, IP addressdata, and/or other location information, such as location informationthat is programmed into the POS device. This location information may becommunicated over a public or private network to the central server. Thelocation information from the mobile device may then be compared withthe location information from the point of sale device to authenticatethe user account at block 422. This ensures that a user of the paymentmedia is the holder of the mobile device since both the payment mediaand the mobile device must be present to complete the transaction,download the mobile application, and provide identity credentials neededto create the account.

In some embodiments, a determination that the location information fromthe mobile device does not match the location information from the pointof sale device may be made at block 424. As an additional authenticationmeasure, one or more challenge questions may be communicated to themobile application at block 426. These challenge questions may bepresented on a display of the mobile device and a user may input answersto the questions. The challenge questions may include questions thatverify previous purchases made using the payment media, informationrelated to an account associated with the mobile device, and/or acombination thereof. A response to the one or more challenge questionsmay be received from the mobile application at block 428. Based on thereceived response or responses, a determination made be made at block430 of whether to authenticate the user account.

Additional authentication measures may compare information known aboutthe owner of the payment account with the owner of an account associatedwith the mobile device to ensure the two owners are the same. Forexample, at block 432, mobile device account information associated withthe mobile device may be received from a carrier network provider of themobile device. The mobile device account information may include useridentity information associated with the user of the mobile deviceaccount. For example, the user's name, address, and/or otheridentification information may be received. At block 434, paymentaccount information associated with the payment media may be received.For example, the payment information may be received from a financialinstitution, such as an issuer of the payment media associated with thepayment account, may provide the payment account information. Thepayment account information may include user identity informationassociated with the user of the payment account. At block 436, the useridentity information from the financial institution may be compared withthe user identity information from the carrier network provider toauthenticate the user account. For example, when the two sets ofidentity information match, it may be determined that the user of thepayment media and the user of the mobile device are one in the same.

Remote Activation of a Transaction Device

In some embodiments, systems and methods are provided for remotelyactivating transaction devices. Transaction devices may include devicesthat are capable of receiving a payment, such as POS devices. Sometransaction devices may also be configured to dispense a product, suchas fuel pumps, vending machines, and the like. While the discussionherein is largely centered around transaction devices such as fuelpumps, it will be appreciated that similar systems and methods may beimplemented with non-dispensing transaction devices, with functionalityrelated to the dispensing of a product being omitted. Users may have theability to remotely select, such as by using a mobile application on amobile device as described in FIGS. 1-5, a particular transactiondevice, a product type, a product amount, and/or a payment type. Usersmay also remotely activate the transaction device, dispense a productfrom the transaction device, deactivate the transaction device, and/orreceive a receipt.

In one example, a customer using a web-based or mobile application mayarrive at a gas station having one or more fuel pumps serving astransaction devices. The customer may select a particular fuel pumpusing the mobile application. The customer may then user the mobileapplication to select a type of fuel to dispense and/or an amount offuel to dispense. The pump may be remotely activated and the customermay pump the fuel. The pump may be deactivated upon dispensing theselected amount of fuel, and a receipt of the transaction may be sent tothe mobile application.

FIG. 5 depicts a system 500 for enrolling a user in a mobile transactionsystem. System 500 may include one or more transaction devices 502, eachconfigured to receive data from mobile applications being executed onmobile devices 504 and/or a server 506 or other computing device of themerchant. Such data may include payment information, product selections,product amounts, activation authorizations, and/or other informationrelated to purchase transactions. The transaction device 502 may be adevice that is capable of conducting a transaction and/or dispenses aproduct. For example, transaction device 502 may include fuel pumps,vending machines, other devices for dispensing products, and/or POSdevices. Transaction device 502 may include a display, a payment reader,and/or one or more input devices, such as a touchscreen, buttons, and/ora keypad, and may be configured to communicate with mobile devices 504and/or servers 506 over one or more networks 508.

Network 508 may be a local area network (LAN) and/or other private orpublic wired and/or wireless networks. Network 508 may utilize one ormore of Wi-Fi, ZigBee, Bluetooth™, Bluetooth™ Low Energy, a cellularcommunications protocol such as 3G, 4G, or LTE, and/or any otherwireless communications protocol. Network 508 may be communicativelycoupled with one or more of the components of the system to facilitatecommunication between the various components. It will be appreciatedthat one or more different network connections may be used in accordancewith the invention, and that the use of a single network 508 to enablecommunications is merely one example of such configurations. Forexample, each component may be communicatively coupled with othercomponents using a separate network for one or more of the connections.

Transaction device 502 may be configured to receive an input selectingthe transaction device 502. For example, a user may approach a gasstation and use a mobile application on the mobile device 504 to selectthe transaction device 502, such as a fuel pump. This selection may becommunicated to the transaction device 502 by the mobile device 504 overnetwork 508 and/or may be received from the mobile device 504 at server506, which may then communicate the selection to the transaction device502. Similarly, a selection of a product type and/or product amount maybe communicated to the transaction device 502. For example, where thetransaction device 502 is a fuel pump, a user may use the mobileapplication to select a fuel type and/or an amount of fuel to dispense.Based on the selected product amount, a payment may be authorized. Forexample, payment information, including an identifier of a paymentaccount, may be transmitted by the mobile application to the to thetransaction device 502 and/or the server 506, which may then communicatean authorization request to a financial institution, such as an issuerof the payment account. The financial institution may respond with anapproval message and the transaction device 502 may be authorized todispense the selected amount of the selected product. In the fuelexample, the fuel pump may be activated and the user may be able to pumpthe selected amount and type of fuel. Upon dispensing the selectedamount of product, the transaction device 502 may be deactivated and apayment receipt may be communicated over network 508 to the mobiledevice 504.

FIG. 6 depicts a flowchart of a process 600 of a method for remotelyactivating a transaction device using a mobile device. Process 600 maybe performed by one or more components of a system such as system 500described above with regard to FIG. 5. For example, process 600 may beperformed by a transaction device, central server, and/or othercomputing device. Process 600 may include receiving a mobile deviceidentifier from a mobile application executed on a mobile device that iswithin a detection range of a transaction device. The mobile deviceidentifier may be associated with the mobile device, such as a phonenumber of the mobile device. The mobile device may automatically sendthe mobile device identifier upon being within the detection range, orthe user may execute the mobile application and provide an input of amerchant associated with the transaction device and/or of thetransaction device itself. Automatic detection of the mobile device maybe done in multiple ways. For example, the merchant and/or transitiondevice may include one or more beacons that emit signals that aredetectable by the user's mobile device when in the detection range. Insome embodiments, the location of the mobile device may be determinedusing the mobile device's GPS sensors and/or other location services.This location may be compared to known locations of merchants and/ortransaction devices, such as locations stored within and/or accessibleby the mobile application.

At block 602, a selection of the transaction device may be received fromthe mobile application. The selection may include an identifierassociated with the transaction device. This is particularly useful inembodiments where multiple transaction devices are present at a singlelocation, as a particular transaction device needs to be activated. Theselection of the transaction device may be done in several manners. Forexample, the user may select a transaction device, such as a fuel pump,from a list or other display of available transaction devices providedby the mobile application. In other embodiments, a short range wirelesssignal, such as NFC, RFID, and/or other signals may be emitted from thetransaction device and/or from a beacon positioned on or near thetransaction device. The signal may include the identifier of thetransaction device such that when received by the mobile device when themobile device is positioned within a detection range of the transactiondevice, the mobile device may communicate the identifier to a centralserver. In other embodiments, a barcode, QR code, and/or other imagepositioned on or near the transaction device may be scanned by themobile device to receive the transaction device identifier, which maythen be communicated to the server.

At block 604, a selection of a transaction amount related to a purchaseof a product may be received from the mobile application. For example, auser may interact with a user interface of the mobile application toselect a dollar amount and/or a product quantity to be dispensed fromthe transaction device. In the context of a fuel pump, the transactionamount may be a dollar amount of fuel to purchase, or may be a quantity,such as a number of liters, gallons, or other quantity of fuel. In somecases, the transaction amount may be an instruction to dispense enoughfuel to fill a fuel tank. In some embodiments, the selection may becommunicated to the transaction device, which may then communicate theselection to the server. In some embodiments, the selection of thetransaction amount and/or the transaction device may include a selectionof a product type to be dispensed. For example, a fuel grade and/or fueltype may be selected. As another example, where a vending machine isserving as a transaction device, a food, beverage, and/or other productto be dispensed may be selected along with the transaction device and/ortransaction amount.

In some embodiments, either prior to, or upon, the transactionauthorization, additional authentication measures may be taken. Forexample, at block 606, location information may be received from themobile device and the point of sale device. This may be done usingnetworks such as network 508 described above. For example, the mobileapplication executed on the mobile device may retrieve locationinformation, such as GPS data and/or other location data from the mobiledevice and provide this location information to the central server overa cellular data network, a Wi-Fi network, and/or other wireless network.In some embodiments, a short range network, such as NFC, Bluetooth™, orother short range wireless network may be used to provide the mobiledevice's location to the transaction device, which may relay thelocation information to the central server. The transaction device maycommunicate its own location to the central server. For example, thetransaction device may retrieve its own GPS data, IP address data,and/or other location information, such as location information that isprogrammed into the transaction device. This location information may becommunicated over a public or private network to the central server. Thelocation information from the mobile device may then be compared withthe location information from the point of sale device to authenticatethe user account at block 608. This ensures that a user of the paymentmedia is the holder of the mobile device since both the payment mediaand the mobile device must be present to complete the transaction,download the mobile application, and provide identity credentials neededto create the account.

In some embodiments, a determination that the location information fromthe mobile device does not match the location information from thetransaction device may be made at block 610. As an additionalauthentication measure, one or more challenge questions may becommunicated to the mobile application at block 612. These challengequestions may be presented on a display of the mobile device and a usermay input answers to the questions. The challenge questions may includequestions that verify purchases made using the payment media,information related to an account associated with the mobile device,and/or a combination thereof. A response to the one or more challengequestions may be received from the mobile application at block 614.Based on the received response or responses, a determination made bemade at block 616 of whether to authenticate the user account.

At block 618, an authorization request may be received for a paymentaccount associated with the mobile device to an issuer of the paymentaccount. The authorization request may be for a transaction of at leastthe transaction amount. For example, prior to dispensing a product, themobile device and/or transaction device may communicate an authorizationrequest to the server to authorize a payment account for the purchase.In some embodiments, the authorization request may be communicated to anissuer of the payment account or other financial institution. Thepayment account may be stored on and/or otherwise linked to the mobileapplication, such as by a user account associated with the mobileapplication. An authorization approval for the transaction may bereceived from the issuer or other financial institution at block 620.Upon receiving the approval, a command or other signal to activate thetransaction device to dispense the product may be sent to thetransaction device at block 622. The signal transmission may be directedto the transaction device based on the identifier associated with thetransaction device. In the fuel pump example, upon activation, the usermay pump an amount of fuel matching the transaction amount. In someembodiments, a notification may be sent indicating that the transactiondevice has been activated or is otherwise ready for use. For example, amessage may be communicated to the mobile device and/or the transactiondevice that alerts the user that the product may be dispensed.Indications may include written messages on a display of the transactiondevice and/or mobile device, and/or may include other audio and/orvisual indications produced by the transaction device and/or the mobiledevice. Upon dispensing the transaction amount, the transaction devicemay be deactivated such that no more product may be dispensed at block624. A receipt of the transaction may be provided to the mobile deviceat block 626. For example, a message or notification may be sent to themobile application and/or and SMS message or email containing a receiptof the purchase may be communicated to the mobile device.

FIG. 7 depicts an embodiment of a user interface 700 of a mobileapplication for selecting a product type and a transaction amount to bedispensed at a transaction device. User interface 700 may includebuttons 702 allowing a user to select a particular product type. Labelsmay be provided on or near each button 702 that indicate a product typeand/or a price per unit of each product. For example, for fuel pumps,each button 702 may be associated with a label for a fuel grade and/or acost per gallon or liter of fuel. User interface 700 may also include atransaction amount selection area 704. Transaction amount selection area704 may include one or more methods of selecting a transaction amount,such as described above in FIGS. 5 and 6. For example, a slider bar 706may be provided that allows the user to select a transaction amount inthe form of a product quantity. As one example, a user may be able toselect a number of gallons of fuel to purchase. A slider bar 708 may beprovided that enables a user to select a transaction amount in the formof a dollar or other currency value. For example, slider bar 708 may beused to select a purchase of $20 of fuel. Rather than use a slider toselect a transaction amount, the user may enter a value in a customvalue field 710. When selected, such as by a user touching a portion ofa display of the mobile device associated with custom value field 710, atouchscreen keyboard may be opened such that the user may enter a value.In some embodiments, custom value field 710 may include a selector ofunits for the custom value, such that the user only needs to input anumber and check a box or otherwise select a unit type for the customvalue.

In gas station embodiments, a fill button 712 may be provided. Byselecting the fill button, a user may set the transaction value asenough fuel to fill the tank. In such embodiments, an authorizationrequest may be submitted to a financial institution for a predeterminedamount. Oftentimes this predetermined amount may be an averagetransition cost and/or a maximum transaction cost. For example, thefinancial institution and/or merchant may select the predeterminedauthorization amount, which may be for a value well in excess of theaverage cost. As one example, a payment account associated with themobile application may be authorized for a truncation for $250, wherethe average transaction cost is closer to $30. This ensures that thepayment account has sufficient funds to cover all or almost alltransaction amounts. Upon filling the tank and deactivating the fuelpump, a final transaction cost may be determined and the purchasetransaction may be processed using this value. In embodiments where auser manipulates slider bar 706 and/or slider bar 708 and/or embodimentswhere a custom value is selected, an authorization request for the exactamount of product may be submitted to a financial institution. Inembodiments where a user selects a transaction amount that is greaterthan the amount of product dispensed, such as where a user selects $20and only $17 of fuel is needed to fill a tank, the final transactionwill be processed based on the amount of product dispensed rather thanthe requested amount. If a user selects a transaction amount below whatis needed to fill a tank, the fuel pump will shut off or otherwisedeactivate upon dispensing the selected transaction amount. The user maythen have the option to select an additional transaction amount or tocomplete the transaction.

In some embodiments, a user may have a particular product type and/ortransaction value that they want to use repeatedly. One or more defaultbuttons 714 may be provided on user interface 700 that allow a user todesignate a particular product type and/or transaction value as adefault selection for future transactions. In some embodiments, defaultbuttons 714 may include an option for a default selection at only aspecific transaction device and/or at all similar transaction devicesthat offer the same and/or similar product types.

FIG. 8 depicts a flowchart of a process 800 for remotely activating atransaction device using a mobile application executed on a mobiledevice. Process 800 may be performed by mobile applications such asmobile application 200 and may include a user interface such as userinterface 700 as described herein. Process 800 may include determiningthat a mobile device is within a detection range of a transaction deviceat block 802. This determination may be made by detecting a signalemitted from a transaction device and/or a beacon positioned on or nearthe transaction device. The signal may include an identifier of thetransaction device such that the mobile application can properlyidentify the particular transaction device. In some embodiments, thedetection may involve retrieving location information of the mobiledevice, such as data from a GPS sensor of the mobile device, andcomparing the location information with known locations of transactiondevices. When the locations match within a predetermined distance range,the mobile device may determine that it is within the detection range ofthe transaction device. In some embodiments, upon detecting that themobile device is within the detection range, the mobile application mayautomatically open a user interface, such as user interface 700 asdescribed above.

The mobile device may provide a mobile device identifier associated withthe mobile device to a computing device, such as server 506, at block804. The mobile device identifier may be a phone number of the mobiledevice or an identifier associated with a particular instance of themobile application such that the server and/or transaction device mayproperly identify the mobile device and/or any payment information orpayment accounts associated with the mobile device. At block 806, aselection of the transaction device may be provided to the computingdevice. The selection may include an identifier associated with thetransaction device such that product selections, transaction amounts,and/or activation commands may be properly directed. The selection ofthe transaction device may be received at a user interface of the mobileapplication, such as user interface 700. In some embodiments, theselection of a transaction device may include a user selecting aparticular transaction device from a list of nearby and/or other knowntransaction devices. In other embodiments, the mobile device may detecta signal from a beacon on or near the transaction device. For example,an NFC, RFID, and/or other beacon may emit a signal that includes theidentifier of the transaction device. When the mobile device is within abroadcast range of the beacon signal, the identifier may be received bythe mobile device for communication to the computing device. In otherembodiments, a camera of the mobile device may be used to scan abarcode, QR code, and/or other image that may provide the identifier tothe mobile device for transmission to the computing device.

At block 808, a selection of a transaction amount related to a purchaseof a product may be received. For example, a user may interact with theuser interface to select a dollar amount and/or a product quantity topurchase and/or have dispensed form the transaction device. For example,a position of a slider, such as slider 708 in FIG. 7, may be used toindicate the transaction amount on the user interface. In someembodiments, this selection may include a product type, such as a fuelgrade. An authorization request for the transaction amount may becommunicated to the computing device at block 810. In embodiments wherea user selects a product quantity as the transaction amount, rather thana dollar amount, a price per unit of the product may be used tocalculate a dollar value of the transaction amount. The transactionamount and/or dollar amount may be included in an authorization requestto a financial institution, such as an issuer of a payment accountassociated with the mobile application, mobile device, and/or userdevice thereof. Upon authorization of the transaction amount, thetransaction device may be activated by the computing device to dispensethe product. In some embodiments, an indication that the transactiondevice is ready for use may be provided on the transaction device and/orthe mobile device. For example, a text-based and/or other visualindication may be produced and/or an audio indication may be emittedfrom a speaker of the transaction device and/or mobile device. Thetransaction device may then dispense the product in the authorizedamount and a receipt of the purchase may be received by the mobiledevice upon the product being dispensed at block 812.

Shared Payment in Mobile Transactions

In some embodiments, systems and methods are provided for providingshared payment solutions for mobile transactions. Such shared paymentsolutions may be especially useful for parents who want their childrento be able to make specific purchases, such as fuel or food purchases,but do not want their children to have their own credit cards. Systemsand methods may provide the ability of a primary user that is verifiedfor mobile transactions and is enrolled in the mobile transaction systemto add additional participants to download and use the mobileapplication to pay for goods and services using the primary user'spayment account. The primary user may have the ability to invitesecondary users to link to the payment account. The primary user mayalso have the ability, using a mobile application such as mobileapplication 200, to provide account restrictions pertaining to whatgoods, services, may be purchased by the secondary user, the dollarvalue threshold that may be spent, the dates or duration for when thesecondary user may make purchases, and/or other restrictions.Additionally, the primary user may have the ability to deactivate thesecondary account at any time. Notifications regarding purchase and usedetails of the secondary user may be sent to the primary user, such asSMS messages, push notifications, emails, phone calls, and/or othercomputer and/or telephonic generated methods.

As one example, a primary user may set up and/or select a paymentaccount to share. The primary user may then select one or more secondaryusers to add to the payment account. The payment account may be linkedto the secondary users. The secondary users may then be notified of theaddition. For secondary users who already have the mobile application,the notification may be a push notification or other applicationspecific notification. The notification may also be via SMS message,email, or other electronic message. Such notifications are particularlyuseful for secondary users who do not have the mobile application. Forsecondary users that do not yet have the mobile application, thenotification may include instructions to download the mobile applicationand/or may include a method of providing access to a download for themobile application. Upon downloading the mobile application, thesecondary user may complete an authentication process and/or registerwith the mobile application. The secondary users may then use thepayment account to complete transactions using the mobile application.

FIG. 9 depicts a process 900 for setting up a shared payment account forconducting mobile transactions. Process 900 may be performed by a serveror other computing device that is in contact with two or more mobiledevices over one or more networks. Process 900 may begin with receivingpayment information from a primary user's mobile application executed ona primary user's mobile device at block 902. The payment information maybe associated with a payment account of the verified primary user. Insome embodiments, the payment account may be previously establishedand/or verified for use with the primary user's mobile applicationand/or account associated therewith for prior use by the primary user inconducting mobile transactions. At block 904, a selection of a secondaryuser to be added as an authorized user of the payment account may bereceived from the primary user's mobile application. The secondary usermay be associated with a user identifier, such as a phone number, emailaddress, and/or a username associated with a mobile application of thesecondary user. The primary user may select the secondary user byinputting the user identifier into the primary user's mobileapplication. In some embodiments, a list of possible secondary users maybe displayed to the primary user. For example, the list may be populatedwith the primary user's phone and/or email contact list.

Along with the selection of the secondary user, the primary user mayprovide restrictions on the use of the payment account. Each secondaryuser may have his own set of restrictions supplied by the primary user.Restrictions may determine what products and/or services the paymentaccount may be used to purchase. Additionally, spending limits may beprovided. The spending limits may be in terms of a number of purchases,a number of a specific type of purchase, a dollar amount, and/or otherspending limit. For example, a primary user may allow a secondary userto fill up a fuel tank once a week, purchase lunch every day, and/orspend $50 per week using the payment account. The restrictions may alsodetermine when and where a secondary user may utilize the paymentaccount. For example, only transactions at a particular merchant may beauthorized and/or transactions during a specific time of day, such as atlunch, may authorized.

Upon receiving the selection of a secondary user, a notification may beprovided to the secondary user that the secondary user has been added bythe verified primary user as an authorized user of the payment accountat block 906. The notification may be directed to the second user usingthe user identifier. For example, if the secondary user already has themobile transaction mobile application, the notification may be a pushnotification and/or other “in-app” notification that uses an identifierassociated with the secondary user's mobile application alerting thesecondary user of the selection. In other embodiments, the notificationmay be directed to the secondary user by SMS, email, or othernon-app-based format. In embodiments where the secondary user does notalready have the mobile transaction mobile application downloaded ontheir mobile device, the notification may include instructions on how todownload the mobile application and/or may provide direct access to thedownload. For example, access to the download may be provided in theform of a link to the download. In some embodiments, a command may besent to the secondary user's mobile device such that the secondary use'smobile device navigates to a download source, such as a website usingthe mobile device's browser and/or a mobile application database. Theuser may then download and install the mobile application.

At block 908 a confirmation message may be received from the secondaryuser's mobile application. The confirmation message may serve as anacceptance by the secondary user to be added as an authorized user onthe payment account, and the confirmation may include authenticationinformation associated with the second user. For example, theauthentication information may include a mobile device and/or useraccount username, password, and/or biometric input to verify that thesecondary user in possession of the secondary mobile device is who theprimary user believes them to be. Additionally, the authenticationinformation may include information related to other authenticationmethods, such as those described elsewhere herein. Upon authentication,the secondary user may be added as an authorized user of the paymentaccount at block 910, and may use the payment account to complete mobiletransactions within any restrictions set by the primary user. In someembodiments, while the secondary user may use the payment account formobile transactions, the payment account details and/or other paymentinformation of the primary user may be hidden from the secondary user.This allows the secondary user to utilize the payment account within anyrestrictions set by the primary user without any risk of the secondaryuser being able to use the payment account and/or other paymentinformation outside of the shared payment using the mobile application.

Another aspect of shared payment systems and methods is the ability of auser to request funds for a specific purchase. A first registered userof a first instance of the mobile application may select, using themobile application, a second registered user of a second instance of themobile application from which to request funds. The second user mayreceive a notification related to the request for funds and select,using the mobile application, whether to approve or deny the request.Upon approval, a payment account associated with the second user'smobile application may be used to conduct the transaction.

As one example, a first user may select a contact, or second user, fromwithin a mobile transaction mobile application. The first user may thensend a request for a transaction amount, such as a dollar amount and/ora product quantity. For example, the first user may request payment forfive gallons of fuel to a gas station. A notification may be sent to thesecond user that funds in the transaction amount have been requested bythe first user. The second user may accept or deny the request using amobile application on their mobile device. Upon acceptance, the firstuser may have the ability to conduct the purchase transaction inreal-time or near real-time. In some embodiments, the first user may berequired to authenticate, such as by providing identify credentials,prior to completing the transaction. This may ensure that the first useris actually the person the second user believes them to be, reducing thelikelihood of fraudulent funds requests. Identity credentials mayinclude a username, a password, a biometric identifier and/or otherindication information. Upon completion of the transaction, the seconduser may receive a receipt of the transaction completed by the firstuser.

FIG. 10 depicts a flowchart of one embodiment of a process 1000 forrequesting funds from another user. Process 1000 may be performed by aserver or other computing device that is in contact with two or moremobile devices over one or more networks. Process 1000 may begin withreceiving a request for a payment from a first mobile applicationexecuted by a first mobile device at block 1002. The request may includea transaction amount and a user identifier associated with a second useraccount and a second mobile device. The transaction amount may include aproduct quantity and/or a dollar value of a purchase. For a request topurchase fuel, a number of gallons or liters of fuel may be includedand/or a dollar value of gas may be requested as the transaction amount.In some embodiments, a request to fill a fuel tank may also be received.The selection of a transaction amount may be done using a user interfaceof a mobile application, such as user interface 700 as described herein.The user identifier may be a phone number, email address, and/or ausername associated with the mobile application and/or second useraccount.

At block 1004, a message may be communicated to the second mobile deviceusing the user identifier to direct the message. The message may includea request to provide funds for the transaction amount. The message mayalso provide a name or other identifier of the first user such that thesecond user knows who is requesting the funds. A user authentication maybe received from the first mobile application at block 1006 to verify anidentity of a user of the first mobile device. This ensures that theuser requesting the funds is the person who the second user believesthem to be. The authentication may be received at any point of therequest process, such as before or while providing a selection of thetransaction amount, while in other embodiments, the authentication maybe done after the second user approves the payment, or anytime therebetween.

An acceptance of the request to provide funds may be received from asecond mobile application being executed by the second mobile device atblock 1008. In some embodiments, the acceptance may include acounteroffer. For example, the second user may be willing to providesome funds to the first user, but not the amount requested. The seconduser may then select a transaction amount value that he is willing topay for. A payment account associated with the second user account maybe authorized for the payment such that the first mobile device maycomplete a related payment transaction in real-time at block 1010. Forexample, an authorization request may be communicated to a financialinstitution associated with the payment account requesting authorizationof a transaction in a dollar amount of the transaction amount. Thefinancial institution may approve or deny the transaction and send theapproval or rejection to the server. Upon completion of the transaction,a receipt of the payment transaction may be sent to the second mobiledevice at block 1012.

In some embodiments, the request may be for funds to make a purchase ata transaction machine, such as those described herein. In suchembodiments, the process 1000 may also include activating a transactiondevice to dispense a quantity of a product matching the transactionamount and deactivating the transaction device upon dispensing thetransaction amount.

Mobile Application Service Scheduler

In some embodiments, systems and methods of scheduling vehicle serviceusing a mobile application are provided. Users are provided the abilityto manually or through electronic means, schedule or directly purchaseservices and/or parts for their vehicle. Users may also have the abilityto purchase fuel and/or other products to be picked up at a merchantand/or service provider. Additionally, the system may send the user amobile notification when a service to the vehicle is due, and mayprovide a scheduling interface to help the user schedule, price, and/orpay for any necessary and/or desired services.

In one example, an odometer reading of a vehicle may be provided to amobile application. This helps alert the application when scheduledservice is due on specific vehicle systems, such as oil changes, tirerotations, and brake pad replacements. The mobile application may beinterfaced with a telematics interface of the vehicle to get automaticupdates of statuses of various vehicle systems. Service notificationsmay be set within the mobile application such that when a certain date,odometer reading, and/or status of a system monitored by the telematicsinterface occurs, a service notification is provided to the user, suchas an SMS, email, push notification and/or other in-app notification.Additionally, the mobile application may provide the user the ability topurchase other goods and services from the merchant and/or serviceprovider. For example, a user may interact with a menu of availableproducts and/or services available from a particular merchant on a userinterface of the mobile application to place an order. The user may payfor the goods and/or services and provide a time for fulfillment of theorder. For example, the user may order food or drink from a merchant andrequest that it be available at a designated time such that the user maypick up the goods upon arrival at the merchant. The user may prepayusing the application so they merely have to pick up the goods.

FIG. 11 depicts a system 1100 for scheduling vehicle service using amobile application. System 1100 may include a mobile device 1102 thatexecutes a mobile application for scheduling vehicle service. Mobiledevice 1102 may interface with various components of a vehicle 1104,such as by communicating with a telematics interface of vehicle 1104using a network 1106. Network 1106 may be a local area network (LAN)and/or other private or public wired and/or wireless networks. Network1106 may utilize one or more of Wi-Fi, ZigBee, Bluetooth™, Bluetooth™Low Energy, a cellular communications protocol such as 3G, 4G, or LTE,and/or any other wireless communications protocol. Network 1106 may becommunicatively coupled with one or more of the components of the systemto facilitate communication between the various components. It will beappreciated that one or more different network connections may be usedin accordance with the invention, and that the use of a single network1106 to enable communications is merely one example of suchconfigurations. For example, each component may be communicativelycoupled with other components using a separate network for one or moreof the connections. Oftentimes, a connection between mobile device 1102and vehicle 1104 may be a Bluetooth™ or similar short range network.

By interfacing with the telematics interface of vehicle 1104, mobiledevice 1102 and/or a mobile application may retrieve data regardingvarious systems of the vehicle. For example, odometer readings, tirepressures, brake pad condition, fluid levels, and the like may beprovided to the mobile device such that service reminders andnotifications may be set and provided to the user. The mobile device1102 may communicate with a merchant system 1108 to schedule serviceappointments and/or to order products and/or services. For example, themobile device 1102 may request a schedule of available appointments froma service computer 1110 of the merchant system 1108. This schedule maybe provided to the user of the mobile device 1102 such that the user mayselect a convenient time for the service appointment. The user may alsopay for any service using the mobile application running on the mobiledevice 1102. Additionally, the mobile application may be used topurchase additional services and/or products using the mobile device1102. For example, a user may wish to purchase food from the merchant orservice provider while the vehicle is being serviced. The mobile device1102 may interface with a merchant computer 1112 of the merchant system1108 to retrieve a menu of available services and/or goods. The user maythen use the mobile application to select a product, such as food, forpurchase. The user may then pick up the food upon his arrival at theservice appointment. Such ordering may be useful in any situation wherequicker transactions are desired, such as when wanting to purchaseconvenience store items while fueling up a vehicle.

FIG. 12 depicts a flowchart of a process 1200 for conducting mobiletransactions using a mobile application. Process 1200 may be performedby a mobile device, such as mobile device 1102, that is executing amobile application, such as those described herein. Process 1200 maybegin with receiving an odometer reading of a vehicle at block 1202. Theodometer reading may be manually input by a user of the mobile deviceand/or may be received by communicatively coupling the mobile device tothe vehicle. For example, the mobile device may be interfaced with atelematics interface of the vehicle at block 1204. A telematics inputmay be received from the telematics interface at block 1206. Thetelematics input may include status of one or more systems of thevehicle. For example, the telematics input may include odometerreadings, tire pressures, brake pad condition, fluid levels, and/orstatuses of other vehicle systems and components. In some embodiments,the telematics input may include one or more service codes of thevehicle. The service codes may indicate that a particular service orother maintenance is needed. One or more service notifications may beset based on the odometer reading and the telematics input at block1208. For example, dates and/or mileages may be set for oil changereminders, tire rotations, tire replacements, brake pad replacements,and/or other services.

At least one of the one or more service notifications may be presentedon a display of the mobile device executing the mobile application atblock 1210. For example, a push notification, other in-app notification,SMS message, email, and/or other notification may be presented on themobile device to alert the user that one or more services should bescheduled. The user may interact with the mobile application to requestto schedule a service appointment related to the at least one of the oneor more service notifications at block 1212. Upon receiving the requestto schedule a service appointment, the mobile device may request aschedule of available service times from a service provider, such as anauto shop. The mobile device may receive the schedule of availableservice times from the service provider at block 1214.

At block 1216, the mobile device and/or mobile application may provide ascheduling user interface that includes the schedule of availableservice times on the display of the mobile device. This allows a user toview available times, estimated costs, and/or other details associatedwith the requested service. A selection of the service appointment maybe received at block 1218. The selection may include at least one of theavailable service times, although in some embodiments, multiple servicetimes may be selected in case a first time is no longer available. Thisselection may be communicated to the service provider at block 1220. Insome embodiments, a confirmation of the service appointment may bereceived from the merchant or service provider. This confirmation may bean SMS, email, push notification, and/or other in app notificationdirected to the mobile application and/or mobile device. Theconfirmation may be presented on a display of the mobile device suchthat the user knows that the appointment scheduling was successful.

In some embodiments, a menu user interface may be provided to the mobiledevice and displayed such that the user may view a menu of products orservices available for purchase from the service provider. For example,food or car washes may be purchased using the mobile application. Anorder may be received as a user selects one or more of the productsand/or services to order. Along with the products and/or services, theorder may contain a selected time to fulfill the order. For example, theuser may wish to pick up the purchase at a particular time, such as whenthe user plans on visiting the merchant, plans on fueling up a vehicle,and/or plans on bringing the vehicle in for service. The user may alsoprovide payment for the selected products and/or services at the time ofordering using the mobile application. The order and/or fulfillment timemay be communicated to the service provider for fulfillment of theorder.

Fraud Prevention and Authentication

Systems and methods are provided for verifying users who are registeringpayment accounts, completing payment transactions with registeredpayment accounts, requesting and/or approving funds from a registeredpayment account, and/or conducting other transactions using the mobiletransaction systems described herein. The verification methods mayreduce fraud associated with enrolling and/or utilizing a paymentaccount with a mobile transaction mobile application. Several differentverification and/or fraud detection techniques may be utilized, such asin the processes described herein, many of which verify that an owner ofthe payment account matches the owner of a mobile device and/or useraccount associated with a mobile application running on the mobiledevice.

As one example, during registration of a credit card with a mobileapplication, magnetic data from the credit card is collected using a POSdevice. The user then enters a phone number associated with his mobiledevice into the POS device, which may cause a message to be sent to themobile device such that a mobile application may be downloaded andinstalled on the user device and a user account may be created andassociated with the credit card account. Location information from themobile device may be compared with a location of the POS device twoensure the user is in possession of both the credit card and the mobiledevice. Additionally, user information may be retrieved from a carrieror service provider of the mobile device, which may be compared withuser information associated with the credit card to determine whetherthe credit card and mobile device are jointly owned.

In some embodiments, upon registration or use of a credit card or otherpayment media associated with a payment account, a financial institutionthat issued and/or maintains the payment account may be queried todetermine whether the payment media has been lost or stolen and/orwhether the payment account has been otherwise compromised.

In some embodiments, challenge questions may be provided on a mobiledevice to ensure that the user of the payment account is authorized touse the payment account. For example, challenge questions related to aprevious use or transaction of the payment account may be presented onthe mobile device. The user may then select a correct answer orotherwise indicate a correct answer, to verify that the user isauthorized to conduct transactions using the payment account. As oneexample, challenge questions may ask a user to select a recenttransaction made using the payment account from a list of possibletransactions that includes the recent transaction, as well as one ormore dummy transactions. In some embodiments, multiple challengequestions may be asked to decrease the likelihood that a person couldcorrectly guess the correct transaction. Such challenge questions may beutilized as a standalone verification measure and/or as a secondaryverification measure, such as when a primary verification measuredetermines that the mobile device user and the credit card user are notone in the same.

It will be appreciated that these and/or other authenticationtechniques, such as biometric authentication and/or a user entering adevice PIN on the device associated with a particular user, may beapplied alone, or in combination, to authenticate users of mobiletransaction mobile applications. Other authentication techniques mayinclude identifying the mobile device using mobile device data availableto the mobile app, identifying the user using user registration datasuch as a name, email id, password, and/or phone number supplied by theuser, and/or by checking against a device blacklist kept by FDC and/orby phone carriers. For example, these lists may include data related tovelocity checking of enrollments for that device. If a user has aparticularly high number of enrollments in a short period, it mayindicate that the device has been stolen and is being used improperly.Additional authentication techniques may also include checking the useragainst a user registration data blacklist kept by FDC. In embodimentswhere multiple authentication techniques are utilized, a weighted scoreof the authentication technique used may be calculated. A finalauthentication decision for the transaction may then be made based onthis weighted score.

FIG. 13 depicts a flowchart of a process 1300 for fraud prevention andauthentication. Process 1300 may be performed by a computing device,such as a server, POS device, and/or transaction device. Process 1300may begin by receiving a request for a transaction at block 1302. Thetransaction may be a request for funds, a request for approval of atransaction, a response to a notification to add an authorized user on apayment account, other authorizations described herein, and/or anyenrollment and/or transaction authorization. At block 1304, two or moreauthentication measures may be performed.

Any form of authorization measures may be performed, such as biometricauthentication. Other examples of authorization measures may includereceiving location information from the mobile device and thetransaction device and comparing the location information from themobile device with the location information from the transaction deviceto authenticate the transaction, such as is described above. In someembodiments, a determination that the location information from themobile device does not match the location information from thetransaction device may be made. One or more challenge questions may becommunicated to the mobile application, and a response to the one ormore challenge questions may be received from the mobile application.

In some embodiments, the authentication measures may include receivingmobile device account information associated with the mobile device froma carrier network provider of the mobile device. The mobile deviceaccount information may include first user identity information. Paymentaccount information associated with the payment account may be received.The payment account information may include second user identityinformation. The first user identity information may be compared withthe second user identity information to authenticate the transaction.

The authentication measures may include comparing a mobile deviceidentifier against a mobile device list of a first third-party system.For example, the mobile device identifier may be compared against ablacklist and/or whitelist maintained by a phone carrier or otherinformation system. Velocity checking of enrollments in differenttransaction systems of a mobile device associated with the mobile deviceidentifier may be made, as excessive enrollment of a mobile device inaccounts may be an indication of fraud. User information of a user ofthe mobile device may be against a user registration data list of asecond third-party system, such as an information system. A password orbiometric input received at the mobile device may be compared with aregistered password to authenticate a user and/or device. Similarly,payment account data may be compared against a payment account list of athird third-party system, such as an information system, issuer of thepayment account, and/or other financial institution.

In some embodiments, the authentication measures may include identifyinga mobile device based on mobile device data available to a mobileapplication executed on the mobile device. For example, the mobiledevice may be able to retrieve information from a device carrier orother system. A user may be identified based on user registration devicereceived by the mobile device. This information may be compared toinformation stored on the mobile device, received by a wireless carrier,financial institution, and/or other third-party source. A paymentaccount may be identified based on payment account data received by themobile device. This data may be verified against information receivedfrom a financial system or other third-party service.

Upon completion of each authentication measure, a result for each of thetwo or more authentication measures may be received at block 1306. Basedon the results of the two or more authentication measures, a weightedscored may be calculated at block 1308. A determination whether toauthenticate the transaction based at least in part on the weightedscore may be made at block 1310.

A computer system as illustrated in FIG. 14 may be incorporated as partof the previously described computerized devices. For example, computersystem 1400 can represent some of the components of the mobile devices,servers, merchant systems, telematics systems, financial institutionsystems, POS devices and/or transaction devices as described herein.FIG. 14 provides a schematic illustration of one embodiment of acomputer system 1400 that can perform the methods provided by variousother embodiments, as described herein, and/or can function as the hostcomputer system, a server, a remote kiosk/terminal, a ticket vendingmachine or other point-of-sale device, a transaction device, a fuelpump, a mobile device, and/or a computer system. FIG. 14 is meant onlyto provide a generalized illustration of various components, any or allof which may be utilized as appropriate. FIG. 14, therefore, broadlyillustrates how individual system elements may be implemented in arelatively separated or relatively more integrated manner.

The computer system 1400 is shown comprising hardware elements that canbe electrically coupled via a bus 1405 (or may otherwise be incommunication, as appropriate). The hardware elements may include aprocessing unit 1410, including without limitation one or moregeneral-purpose processors and/or one or more special-purpose processors(such as digital signal processing chips, graphics accelerationprocessors, and/or the like); one or more input devices 1415, which caninclude without limitation a mouse, a keyboard, a touchscreen, receiver,a motion sensor, a camera, a smartcard reader, a contactless mediareader, and/or the like; and one or more output devices 1430, which caninclude without limitation a display device, a speaker, a printer, awriting module, and/or the like.

The computer system 1400 may further include (and/or be in communicationwith) one or more non-transitory storage devices 1435, which cancomprise, without limitation, local and/or network accessible storage,and/or can include, without limitation, a disk drive, a drive array, anoptical storage device, a solid-state storage device such as a randomaccess memory (“RAM”) and/or a read-only memory (“ROM”), which can beprogrammable, flash-updateable and/or the like. Such storage devices maybe configured to implement any appropriate data stores, includingwithout limitation, various file systems, database structures, and/orthe like.

The computer system 1400 might also include a communication interface1430, which can include without limitation a modem, a network card(wireless or wired), an infrared communication device, a wirelesscommunication device and/or chipset (such as a Bluetooth™ device, an503.11 device, a Wi-Fi device, a WiMax device, an NFC device, cellularcommunication facilities, etc.), and/or similar communicationinterfaces. The communication interface 1430 may permit data to beexchanged with a network (such as the network described below, to nameone example), other computer systems, and/or any other devices describedherein. In many embodiments, the computer system 1400 will furthercomprise a non-transitory working memory 1435, which can include a RAMor ROM device, as described above.

The computer system 1400 also can comprise software elements, shown asbeing currently located within the working memory 1435, including anoperating system 1440, device drivers, executable libraries, and/orother code, such as one or more application programs 1445, which maycomprise computer programs provided by various embodiments, and/or maybe designed to implement methods, and/or configure systems, provided byother embodiments, as described herein. Merely by way of example, one ormore procedures described with respect to the method(s) discussed abovemight be implemented as code and/or instructions executable by acomputer (and/or a processor within a computer); in an aspect, then,such code and/or instructions can be used to configure and/or adapt ageneral purpose computer (or other device) to perform one or moreoperations in accordance with the described methods.

A set of these instructions and/or code might be stored on acomputer-readable storage medium, such as the storage device(s) 1435described above. In some cases, the storage medium might be incorporatedwithin a computer system, such as computer system 1400. In otherembodiments, the storage medium might be separate from a computer system(e.g., a removable medium, such as a compact disc), and/or provided inan installation package, such that the storage medium can be used toprogram, configure and/or adapt a general purpose computer with theinstructions/code stored thereon. These instructions might take the formof executable code, which is executable by the computer system 1400and/or might take the form of source and/or installable code, which,upon compilation and/or installation on the computer system 1400 (e.g.,using any of a variety of generally available compilers, installationprograms, compression/decompression utilities, etc.) then takes the formof executable code.

Substantial variations may be made in accordance with specificrequirements. For example, customized hardware might also be used,and/or particular elements might be implemented in hardware, software(including portable software, such as applets, etc.), or both. Moreover,hardware and/or software components that provide certain functionalitycan comprise a dedicated system (having specialized components) or maybe part of a more generic system. For example, a risk management engineconfigured to provide some or all of the features described hereinrelating to the risk profiling and/or distribution can comprise hardwareand/or software that is specialized (e.g., an application-specificintegrated circuit (ASIC), a software method, etc.) or generic (e.g.,processing unit 1410, applications 1445, etc.) Further, connection toother computing devices such as network input/output devices may beemployed.

Some embodiments may employ a computer system (such as the computersystem 1400) to perform methods in accordance with the disclosure. Forexample, some or all of the procedures of the described methods may beperformed by the computer system 1400 in response to processing unit1410 executing one or more sequences of one or more instructions (whichmight be incorporated into the operating system 1440 and/or other code,such as an application program 1445) contained in the working memory1435. Such instructions may be read into the working memory 1435 fromanother computer-readable medium, such as one or more of the storagedevice(s) 1435. Merely by way of example, execution of the sequences ofinstructions contained in the working memory 1435 might cause theprocessing unit 1410 to perform one or more procedures of the methodsdescribed herein.

The terms “machine-readable medium” and “computer-readable medium,” asused herein, refer to any medium that participates in providing datathat causes a machine to operate in a specific fashion. In an embodimentimplemented using the computer system 1400, various computer-readablemedia might be involved in providing instructions/code to processingunit 1410 for execution and/or might be used to store and/or carry suchinstructions/code (e.g., as signals). In many implementations, acomputer-readable medium is a physical and/or tangible storage medium.Such a medium may take many forms, including but not limited to,non-volatile media, volatile media, and transmission media. Non-volatilemedia include, for example, optical and/or magnetic disks, such as thestorage device(s) 1435. Volatile media include, without limitation,dynamic memory, such as the working memory 1435. Transmission mediainclude, without limitation, coaxial cables, copper wire and fiberoptics, including the wires that comprise the bus 1405, as well as thevarious components of the communication interface 1430 (and/or the mediaby which the communication interface 1430 provides communication withother devices). Hence, transmission media can also take the form ofwaves (including without limitation radio, acoustic and/or light waves,such as those generated during radio-wave and infrared datacommunications).

Common forms of physical and/or tangible computer-readable mediainclude, for example, a magnetic medium, optical medium, or any otherphysical medium with patterns of holes, a RAM, a PROM, EPROM, aFLASH-EPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread instructions and/or code.

The communication interface 1430 (and/or components thereof) generallywill receive the signals, and the bus 1405 then might carry the signals(and/or the data, instructions, etc. carried by the signals) to theworking memory 1435, from which the processor(s) 1405 retrieves andexecutes the instructions. The instructions received by the workingmemory 1435 may optionally be stored on a non-transitory storage device1435 either before or after execution by the processing unit 1410.

The methods, systems, and devices discussed above are examples. Someembodiments were described as processes depicted as flow diagrams orblock diagrams. Although each may describe the operations as asequential process, many of the operations can be performed in parallelor concurrently. In addition, the order of the operations may berearranged. It will be understood that embodiments disclosed in abovemay include more or less features, depending on desired functionality. Aprocess may have additional steps not included in the figure. Theprocesses and systems described herein may be combined in part and/or inwhole with one another in some embodiments. Furthermore, embodiments ofthe methods may be implemented by hardware, software, firmware,middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middleware,or microcode, the program code or code segments to perform theassociated tasks may be stored in a computer-readable medium such as astorage medium. Processors may perform the associated tasks.

What is claimed is:
 1. A computing system for remotely activating atransaction device, comprising: at least one processor; and at least onememory having instructions stored thereon that, when executed by the atleast one processor, cause the at least one processor to: receive, froma mobile device, a transaction device identifier; receive, from thetransaction device, an authorization request associated with a paymentaccount for a transaction at the transaction device; receive locationinformation from the mobile device and location information from thetransaction device in response to receiving the authorization request;compare the location information from the mobile device with thelocation information from the transaction device to determine whetherthe mobile device is in proximity to the transaction device; and upondetermining that the mobile device is in proximity to the transactiondevice: determine an authorization status of the authorization request;and transmit a signal to activate the transaction device to complete thetransaction, wherein the signal is transmitted based on the transactiondevice identifier.
 2. The computing system of claim 1, wherein theinstructions further cause the at least one processor to: receive amobile device identifier from the mobile device; associate the mobiledevice identifier with the payment account; and receive paymentinformation from the payment account for the transaction.
 3. Thecomputing system of claim 1, wherein the instructions further cause theat least one processor to: transmit, to the transaction device, adeactivation instruction to deactivate the transaction device upondispensing a product associated with the transaction; and provide areceipt of the transaction to the mobile device.
 4. The computing systemof claim 1, wherein the instructions further cause the at least oneprocessor to: transmit, to an issuer of the payment account, theauthorization request for the payment account; and receive, anauthorization approval for the transaction from the issuer.
 5. Thecomputing system of claim 1, wherein the instructions further cause theat least one processor to: receive, from the mobile device, anindication of a transaction amount related to a purchase of a productassociated with the transaction, wherein the authorization requestcomprises a purchase amount based at least part on the transactionamount.
 6. The computing system of claim 5, wherein the transactionamount comprises one or more of a monetary amount or a quantity of theproduct to be dispensed.
 7. The computing system of claim 1, wherein theinstructions further cause the at least one processor to receive aselection of a product to be dispensed.
 8. The computing system of claim1, wherein the instructions further cause the at least one processor tosend a notification to the mobile device that the transaction device isready for use, and wherein the transaction device includes a fuel pump.9. The computing system of claim 8, wherein the instructions furthercause the at least one processor to receive a selection of a fuel grade.10. A computer program product embodied on a non-transitory computerreadable medium comprising instructions, that when executed by at leastone processor, cause the at least one processor to: receive, from amobile device, a transaction device identifier; receive, from thetransaction device, an authorization request associated with a paymentaccount for a transaction at the transaction device; receive locationinformation from the mobile device and location information from thetransaction device in response to receiving the authorization request;compare the location information from the mobile device with thelocation information from the transaction device to determine whetherthe mobile device is in proximity to the transaction device; and upondetermining that the mobile device is in proximity to the transactiondevice: determine an authorization status of the authorization request;and transmit a signal to activate the transaction device to complete thetransaction, wherein the signal is transmitted based on the transactiondevice identifier.
 11. The computing program product of claim 10,wherein the instructions further cause the at least one processor to:receive a mobile device identifier from the mobile device; associate themobile device identifier with the payment account; and receive paymentinformation from the payment account for the transaction.
 12. Thecomputing program product of claim 10, wherein the instructions furthercause the at least one processor to: transmit, to the transactiondevice, a deactivation instruction to deactivate the transaction deviceupon dispensing a product associated with the transaction; and provide areceipt of the transaction to the mobile device
 13. The computingprogram product of claim 10, wherein the instructions further cause theat least one processor to: transmit, to an issuer of the paymentaccount, the authorization request for the payment account; and receivean authorization approval for the transaction from the issuer.
 14. Thecomputing program product of claim 10, wherein the instructions furthercause the at least one processor to: receive, from the mobile device, anindication of a transaction amount related to a purchase of a productassociated with the transaction, wherein the authorization requestcomprises a purchase amount based at least part on the transactionamount.
 15. The computing program product of claim 14, wherein thetransaction amount comprises one or more of a monetary amount or aquantity of the product to be dispensed.
 16. The computing programproduct of claim 10, wherein the instructions further cause the at leastone processor to receive a selection of a product to be dispensed. 17.The computing program product of claim 10, wherein the instructionsfurther cause the at least one processor to send a notification to themobile device that the transaction device is ready for use, and whereinthe transaction device includes a fuel pump.
 18. The computing programproduct of claim 17, wherein the instructions further cause the at leastone processor to receive a selection of a fuel grade.
 19. A methodcomprising: receiving, from a mobile device, a transaction deviceidentifier; receiving, from the transaction device, an authorizationrequest associated with a payment account for a transaction at thetransaction device; receiving location information from the mobiledevice and location information from the transaction device in responseto receiving the authorization request; comparing the locationinformation from the mobile device with the location information fromthe transaction device to determine whether the mobile device is inproximity to the transaction device; and upon determining that themobile device is in proximity to the transaction device: determining anauthorization status of the authorization request; and transmitting asignal to activate the transaction device to complete the transaction,wherein the signal is transmitted based on the transaction deviceidentifier.
 20. The method of claim 19, further comprising: receiving amobile device identifier from the mobile device; associating the mobiledevice identifier with the payment account; and receiving paymentinformation from the payment account for the transaction.